home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Internet Tools 1995 April / Internet Tools.iso / infoserv / www / cern / dev / www-talk.9301-9306.Z / www-talk.9301-9306 / text0335.txt < prev    next >
Encoding:
Text File  |  1995-04-24  |  7.0 KB  |  197 lines
  1. > Date: Thu, 12 Nov 92 14:41:02 CST
  2. > From: Dan Connolly <connolly@pixel.convex.com>
  3. > 
  4.  
  5. > 
  6.  
  7. > >How about ...using
  8. > >
  9. > >> <dd><a HREF="wais://quake.think.com/INFO" RELATIONSHIP=SEARCHME>search</a>
  10. > 
  11.  
  12. > Sure... I don't have any strong opinions about the syntax, except that
  13. > RELATIONSHIP is longer than 8 characters, and that will be an issue
  14. > with some SGML parsers.
  15.  
  16. Of course. We could call it REL.  (That's what you get with IBM-derived  
  17. products ;-)
  18.  
  19. > This opens up the discussion of link semantics from a while ago. Some
  20. > folks suggested a TYPE or ACTION or RELATIONSHIP attribute on anchors:
  21. > 
  22.  
  23. > SEE    (the default) see HREF, i.e. this anchor refers to HREF
  24. > INCLUDE    include HREF at this point in the document (for quoting)
  25. > REPLACE    replace the anchor text with HREF (another quoting mechanism)
  26. > AUGMENT    display HREF along with this document (for figures, etc.)
  27. > SEARCH    search HREF and display the results
  28. >
  29. > You could have zillions of options here: DEFINE (HREF defines this anchor),
  30. > UPDATE (HREF is a new version of this document), TRANSLATE (HREF is
  31. > some converted form of this document). But I suggest we call the attribute
  32. > ACTION, and only create a new one when there is a user-interface impact.
  33. > So the ACTION attribute is a hint from the author on how to display
  34. > the document. That way, all the DEFINE, UPDATE, TRANSLATE, etc fall under
  35. > SEE above.
  36.  
  37. There seem to be two classes of attribute we are talking about here.
  38. Some attributes express a relationship between the documents (or
  39. relationships between objects described by the documents). These are
  40. relationships like
  41.  
  42.     A    is a previous version of    B
  43.     A    describes the author of        B
  44.     
  45. etc.  These add semantics to the web, allow interesting navigational
  46. functions.
  47.  
  48. Other attributes are directions to the client app., to so something:
  49.  
  50.   When you display A, also display B
  51.   When you display A, embed B
  52.   When you print A, also print B
  53.   When you follow this link, embed B
  54.   When you follow this link, search B
  55.   
  56.  
  57. Let's bear in mind the idea of moving toward arbitrary objects.
  58. The OO paradigm (the current one, not the only possible one)
  59. has objects which each have a class, which has a set of
  60. methods, each of which has a set of parameters, each of which
  61. has a class. Ok?
  62.  
  63. Suppose documents are objects. We have two methods now,
  64.  
  65.     render()      returning HTML
  66.     search(text)    returning HTML
  67.  
  68. each taking the object ID as an implicit parameter. That's OK.
  69. These are neat functions. Suppose we generalize.
  70.  
  71. First generalization: the render():HTML is only one of many functions
  72. which the object supports. The format negotiation says
  73. "I want render()* where * is preferably ....".
  74.  
  75. In this context the <ISINDEX> tag means "The class of this object
  76. supports search(text):HTML method".  The SEARCHME link
  77. looks more like some advance notice type information [[yuk -- I hate
  78. having info in two places... links can get out of date -- but never mind]]
  79.  
  80.     "The object references supports search()"
  81.     
  82. plus also the client advice 
  83.  
  84.  
  85.   "When you follow this link, search B"
  86.  
  87. I would separate these two things, personally myself. the first is useful
  88. for deciding on the icon to display, without the second which coud
  89. independently be any of the other client hints mentioned above.
  90.  
  91. In this light, it would seem there are some obvious extentions!
  92. Let's skip the debate about whether you want the client advice attribute
  93. to make an automatic search (OK, let's put it in, no harm in it)
  94. and focus on the type declaration. Whether it is declariung stuff
  95. about the document itself or a related document is a trivial difference,
  96. the difference between the LINK and the A tags, in fact.
  97.  
  98. So lets generalize ISINDEX. We have a choice. We can declare the class
  99. (or any superclass) of an object. Or we can declare a method. In fact,
  100. in the multiple inheritance view, these are very similar as you can
  101. imagine a class which only supports one method, and then construct
  102. classes out of inheritance only from those classes. So declaring a
  103. class (set of methods) is more general than declaring a method.
  104.  
  105. An immediate application of this will be declaring things like
  106. Z39.50 objects which support various search methods with all kinds
  107. of different input parameters.  But one wouldn't of couse stop there....
  108.  
  109. Classes, like representations, would have to be registered. Either registered
  110. or defined in a suitable language by a document. Ha! we know how to handle  
  111. that.. we don't even have to worry about the class description language
  112. because we can apply format negotiation to that.  In fact, registreation
  113. of a class with IANA would involve storing the class description in a document  
  114. was in a well-defined place, and of which everyone would take copies.
  115. I mean like maybe even at compile time for classic classes.
  116. (I would expect that a convention for getting an icon graphic from
  117. the same directory as the class description would be kinda nice.)
  118.  
  119. So a document start with information about itself
  120.  
  121.     <!doctype HTML USDN=x.500:/ch/cern/cn/92/tbl
  122.     URL=http://info.cern.ch/tbl/mydoc.html>
  123.     URL=ftp://info.cern.ch/pub/www/doc/mydoc.html>
  124.  
  125.     <type USDN=x.500:/internet/iana/www/textindex
  126.     URL=http://www.iana.net/class/www/textindex.asn1
  127.     ACTION=textsearch>
  128.  
  129.     Hi this is an index of all the widgets in the wdgetbox.
  130.  
  131. We need one (1) language to start with for defining the classes.
  132. ASN/1 or a SGML version of ASN/1? So long as it can include
  133. inheritance from other classes using a hypertext reference.
  134.  
  135. We still require all documents to be renderable, which just means
  136. that all objects support render() returning either HTML or
  137. ascii.
  138.  
  139.  
  140. > >The argument for the W3 model is that often the user will want to search
  141. > >or not search a single index, and he doesn't want two operations: one to
  142. > >select the fact that he wants to search (click) and one to search
  143. > >(typetypetyepe return).  He just wants one.
  144. > 
  145.  
  146. > But in practice, it's the same: if I quote a wais source from this
  147. > mail message, you'll have to 1) traverse the link to the index,
  148. > and 2) search the index.
  149.  
  150. Like with the chicken and the egg, it depends when you start counting the
  151. clicks.
  152.  
  153. > 
  154.  
  155.  
  156.  
  157.  
  158. > It makes sense to me to have the links mirror protocol transactions.
  159. > In other words, if we have a two step protocol:
  160. > 
  161.  
  162. > client: "I want to do a search."
  163. > server: "OK... here's the query form."
  164. > client: "Here's the filled-out query form."
  165. > server: "OK... here are the results."
  166.  
  167. Isn't that slower? In fact what happens is the user thinks like
  168. that, but the client, knowing that a search is possible, happens
  169. to put up the search panel.  Could we in fact use a 
  170.  
  171. "when you display A, display B too" link, here?
  172.  
  173.  
  174. >... 
  175.  
  176. > I don't think the network will ever be a non-issue.
  177. > 
  178.  
  179. I agree. Speed of light, for one thing.
  180.  
  181.  
  182. > Sure... we need to treat <ISINDEX> as shorthand for
  183. > <A NAME="k" HREF=_this_document_ ACTION=SEARCH></a>
  184. > 
  185.  
  186. > As for making it global to the document, you could just treat the
  187. > first SEARCH anchor as the default index to search.
  188.  
  189. I would prefer to use a document-wide LINK element
  190. in the header as a document-wide analogue of the A element
  191. but that's a detail.
  192.  
  193.     Tim
  194.     
  195.  
  196.  
  197.